=over

=item kill SIGNAL, LIST

=item kill SIGNAL
X<kill> X<signal>

Sends a signal to a list of processes.  Returns the number of arguments
that were successfully used to signal (which is not necessarily the same
as the number of processes actually killed, e.g. where a process group is
killed).

    my $cnt = kill 'HUP', $child1, $child2;
    kill 'KILL', @goners;

SIGNAL may be either a signal name (a string) or a signal number.  A signal
name may start with a C<SIG> prefix, thus C<FOO> and C<SIGFOO> refer to the
same signal.  The string form of SIGNAL is recommended for portability because
the same signal may have different numbers in different operating systems.

A list of signal names supported by the current platform can be found in
C<$Config{sig_name}>, which is provided by the L<C<Config>|Config>
module.  See L<Config> for more details.

A negative signal name is the same as a negative signal number, killing process
groups instead of processes.  For example, C<kill '-KILL', $pgrp> and
C<kill -9, $pgrp> will send C<SIGKILL> to
the entire process group specified.  That
means you usually want to use positive not negative signals.

If SIGNAL is either the number 0 or the string C<ZERO> (or C<SIGZERO>),
no signal is sent to the process, but L<C<kill>|/kill SIGNAL, LIST>
checks whether it's I<possible> to send a signal to it
(that means, to be brief, that the process is owned by the same user, or we are
the super-user).  This is useful to check that a child process is still
alive (even if only as a zombie) and hasn't changed its UID.  See
L<perlport> for notes on the portability of this construct.

The behavior of kill when a I<PROCESS> number is zero or negative depends on
the operating system.  For example, on POSIX-conforming systems, zero will
signal the current process group, -1 will signal all processes, and any
other negative PROCESS number will act as a negative signal number and
kill the entire process group specified.

If both the SIGNAL and the PROCESS are negative, the results are undefined.
A warning may be produced in a future version.

See L<perlipc/"Signals"> for more details.

On some platforms such as Windows where the L<fork(2)> system call is not
available, Perl can be built to emulate L<C<fork>|/fork> at the
interpreter level.
This emulation has limitations related to kill that have to be considered,
for code running on Windows and in code intended to be portable.

See L<perlfork> for more details.

If there is no I<LIST> of processes, no signal is sent, and the return
value is 0.  This form is sometimes used, however, because it causes
tainting checks to be run.  But see
L<perlsec/Laundering and Detecting Tainted Data>.

Portability issues: L<perlport/kill>.

=back